![(レポート)[ServerlessConf London] 「 Cloud Custodian, a serverless rules engine for the cloud」 #serverlessconf](https://devio2023-media.developers.io/wp-content/uploads/2016/10/serverless.jpg)
(レポート)[ServerlessConf London] 「 Cloud Custodian, a serverless rules engine for the cloud」 #serverlessconf
概要
本レポートは2016年10月26日(水)〜28日(金)に開催されたServerlessConf Londonのセッション"Cloud Custodian, a serverless rules engine for the cloud" のレポートです。
本セッションのスピーカーは Capital One でテクニカルフェローを務める Kapil Thangavelu さんです。
アメリカでも有数の金融持株企業である Capital One の名前は AWS の「エンタープライズ」や「金融」などの事例で耳にしたことがある人も多いのではないかと思います。
各サービスをAWSに移行し、大量の AWS アカウントに対してコスト、コンプライアンス、セキュリティなどを統一的に管理する要請がうまれ、Capital One は Cloud Custodian というツールを自社開発し、その後 OSS 化しました。 "custodian" は 「守衛」や「管理人」と言った意味があります。
弊社を含めて、まとまった数の AWS アカウントを管理する会社は、作り込み度はともかく、似たようなツールを持っているかと思います。
Capital One のソリューションに耳を傾けてみましょう。
発表資料
動画
スライド
見当たらず
Cloud Custodian とは?
- Cloud CustodianはCapital Oneが開発したAWSアカウントを管理するルールエンジン
- 従来はプロジェクトごとにエンジニアが独自の方法でAWSのリソース管理を行っていた。
- Capital Oneとして一貫した統制をおこない、アカウントの利用状況を俯瞰できるようにするために生まれた
- エンタープライズ的な要請から生まれたが、インストールは簡単で、スケールし、管理も楽なので、「エンタープライズ」の響きからくるような堅苦しさはない
- たくさんあるプロジェクトでエンジニアにルールを徹底するのは難しい
- Cloud Custodianを使うとエンジニアがなにかルール違反を犯したときに、違反状態を解除し、失敗を犯したエンジニアにルール違反内容を通知できる
- ルールの例
- セキュリティーグループがゆるゆるでEC2インスタンスを起動した
- 暗号化を有効せずにEBS を利用している
- Capital One全体では1500ルールが存在する
- ルールに関するデータの推移はリアルタイムでダッシュボードに表示される
どういう風に設定するの?
- 設定は YAML DSL
- AWS Lambda と AWS CloudWatch Eventsを活用
- 独自のサーバーレスフレームワークを利用(1年前はAWSサーバーレスアーキテクチャー用のフレームワークはなかった)
- 実行結果は S3/CloudWatch Logs, Cloud Watch Metrics などに出力
設定例
- name: require-rds-encrypt-and-non-public
resource: rds
mode:
type: cloudtrail
events:
- CreateDBInstance
filters:
- or:
- Encrypted: false
- PubliclyAccessible: true
actions:
- type: delete
skip-snapshot: true
- mode: 監視対象を指定
- filters: 抽出条件を指定
- actions: 条件を見たした時のアクションを指定
多段ワークフロー
- 不正なインスタンスは1日で停止させる
- 3日後には破棄させる というようなケースも、ポリシーを連結させることで実現可能
最近の発展
- 2016年4月のAWS Chicago summitでCloud Custodianを公表したばかり
- まだ新しいくて、対象リソースやフィルターやアクションはどんどん増えている
Custodian Capabilities
結局 Cloud Custodian で何が出来るの?
- 暗号化
- バックアップ
- GC
- 不使用リソースの操作
- オフピーク時のリソース操作
- タグ・コンプライアンス
- セキュリティグループ・コンプライアンス
どうやってうごいているの?
Modes
- ポーリング:Lambdaをつかわない。
- 定期実行:AWS CloudWatch EventsのPollモードを利用
- AWS CloudWatch Events:API 呼び出しに対してセマンティックな振る舞いを定義
- AWS Config Rules:ポリシーをAWS Configのcustom config ruleとしてプロビジョン
ポリシーに応じて、S3イベントとLambdaを連携させるなど、適切にプロビジョニングする。
公式ドキュメントにあるアーキテクチャー図を見ると、メッセージの流れ方が理解しやすいかと思います。
ポリシーを満たさなかったときはいきなり対象リソースを削除することも出来るけれども、実際の運用では、事前にメール通知して対応を促し、いきなり削除するようなことはしていない。
Development
- GitHub でポリシーを管理している
- PRベースでポリシーの変更を加える
- GitHubと連携したCIの仕組みがあり、dry run実行し、変更内容を事前確認している
Installation
インストールはコマンド一発。 面倒なDBやウェブサーバーのインストールなどは不要
$ pip install c7n
適用するポリシーのYAMLファイルを引数で渡して実行すれば完了
$ custodian run -c my_policy.yml -s output_dir
ユースケース
- 夜間や週末には開発環境のリソースを落とすポリシーを設定 → 64%のコスト削減
- リソースを作成したユーザーをタグで記録する
- 14日間DB接続のないRDBインスタンスを停止させる
- オーバーサイズなRDSインスタンスをダウンサイズさせる
- インターネットフェイシングなELBにぶら下がるEC2インスタンスにはIAMインスタンスプロファイルがないこと
- 特定のポート以外の通信を許可しているセキュリティグループを探す
- CloudTrail が有効になっていないリージョンを探す
- AutoScaling Group 配下のインスタンスのEBSボリュームが暗号化されているかチェック
- S3 にPutするオブジェクトは暗号化されていること、
補足
- 任意のCloudWatch メトリクスはフィルター条件に使えるので#3, #4 のようなことが可能。
- Cloud Custodian は AWS のスイスアーミーナイフとして活躍
- S3/ECS/SQS など様々なサービスのリソースにアタッチされたIAMポリシーの設定が正しいかチェックすることは非常に重要
今後のロードマップについて
短期
- ドキュメント
- ロック・差分・リバート
- ネットワークサポート
- AWS以外の対応
長期
- Cloud Trail の分析
- メール送信
- S3 スキャンのスケールアウト
- Sentry と CloudWatch Logsの連携
AWS Lambda のウィッシュリスト
- Lamba の ARN も CloudTrail ログからわかるようにしてほしい
- 環境・束縛変数
- Lambda関数のタグ付けなどによって利用明細をもう一段階ブレイクダウンしたい
- 詳細なエラーレポート。特にタイムアウト系は原因の追求が難しい
まとめ
リソース・フィルター・アクションを組み合わせ、AWS Lambda を中心にサーバーレスにフットワーク軽くリソース管理できるのは魅力的です。
現時点では公式ドキュメントが貧弱で、各機能をチェックするのは若干敷居が高そうですが、機会を見て Cloud Custodian を評価してみたいと思います。
